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BACKGROUND OF THE INVENTION 

Field of the Invention 

The present invention relates generally to systems and methods for managing 
purchasing data, and more particularly, to methods and systems for managing 
purchasing data of a plurality of entities in order to facilitate the creation and operation 
of purchasing consortiums. 
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Description of the Related Art 

Purchasing consortiums make it possible to achieve better prices on purchased 
goods and services on behalf of the member entities of the consortium, such as 
individual companies or organizations, through volume negotiating and buying. 
However, to successfully form and operate a purchasing consortium, it is important to 
have an accurate picture of the purchasing needs of the member entities. 

Specifically, data obtained with respect to the member entities should include the 
total amount spent by each entity in the consortium, the quality and types of purchases 
made by each entity, and the suppliers from whom each entity purchases goods or 
services. All of the data from the individual entities must be compiled into a portfolio, 
which contains valuable information about the purchasing activities of the consortium as 
a whole. This data includes the total amount spent by the consortium members on each 
type of good or service, as well as the degree of supplier concentration among member 
entities. 

Most companies and organizations have a vast amount of valuable purchasing 
data in their back-office systems. However, this data is often difficult to access. 



; because the systems in which the data resides were designed for other purposes. Even 
i if it were possible to easily extract this data, analysis of the purchasing data of the 
j member entities would remain difficult, due to the thousands of ways those entities 
j structure their data and categorize their purchases. Even within a single entity itself, 
5 each department may structure this purchasing data differently. 

Further, some of the purchasing data may be incomplete, or may contain 
|; inaccurate or incorrectly entered information. In this case, even if the data can be 
{■ extracted, it would be difficult to determine which entities use the same products as well 
I as the same suppliers of those products. If the consortium cannot determine matching 
10 i; products and suppliers amongst the member entities, then the consortium cannot 
j; successfully utilize its volume leverage to obtain better prices for its members. 

Thus, in order to facilitate the creation and operation of a purchasing consortium, 
\\ there is a need for a system that can obtain purchasing data from a variety of member 

■ entities (as well as the departments within those entities) and organize that data so as 

i: 

15 j: to clearly display what products and services are purchased by the member entities and 

li from whom these products and services are purchased. Further, there is a need for 

I such a system to be able to analyze the purchasing data to obtain Information used to 

■ negotiate better prices on products and services purchased by member entities of the 
1 consortium. 
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SUMMARY OF THE INVENTION 

Systems and methods consistent with the present invention manage the 
purchasing data of purchasing entities. The systems and methods can efficiently and 
automatically analyze the purchasing activity of the entities to prepare information used 
to form and operate purchasing consortiums. 

Specifically, systems and methods consistent with the present invention receive 
purchasing data from a purchasing entity. The purchasing data relates to purchase 
transactions for a plurality of products purchased by the purchasing entity. After 
receiving the purchasing data, the system identifies, for each transaction, a product 
related to the transaction by comparing the received purchasing data with product 
information stored in a product index. The product information in the index associates 
at least a portion of the received purchasing data with a particular product. The system 
then modifies the received purchasing data to include data representing the identified 
product and processes the modified purchasing data to reflect all purchase transactions 
concerning the identified product. 

Additional objects and advantages of the invention will be set forth in part in the 
description which follows, and in part will be obvious from the description, or may be 
learned by practice of the invention. The objects and advantages of the invention will 
be realized and attained by means of the elements and combinations particularly 
pointed out in the appended claims. 

It is to be understood that both the foregoing general description and the 
following detailed description are exemplary and explanatory only and are not restrictive 
of the invention, as claimed. Further features and/or variations may be provided in 



3 



addition to those set forth herein. For example, the present invention may be directed 
to various combinations and subcombinations of the disclosed features and/or 
combinations and subcombinations of several further features disclosed below in the 
detailed description. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The accompanying drawings, which are incorporated in and constitute a part of 
this specification, illustrate one embodiment of the invention and together with the 
description, serve to explain the principles of the invention. In the drawings: 

Fig. 1 illustrates a block diagram of a purchasing management system consistent 
with the present invention; 

Fig. 2 is an exemplary flow chart of a method for managing and adding value to 
purchasing data; 

Fig. 3 is an exemplary flowchart illustrating the step of receiving purchasing data; 
Fig, 4 is an exemplary flowchart illustrating the step of identifying suppliers; 
Fig. 5 is an exemplary flowchart illustrating the step of identifying product data 
associations; 

Fig. 6 is an exemplary flow chart illustrating one embodiment of the step of 
updating the system; 

Fig. 7A is an exemplary report, consistent with reports generated by the system; 

and 



Fig. 7B is an alternate exemplary report, consistent with reports generated by the 



system. 
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Overview 

Systems and methods consistent with the present invention manage purchasing 
data from entities belonging to a purchasing consortium. The system receives from 
each member entity purchasing data that describes all purchase transactions made by 
that entity. Typically, this purchasing data describes the supplier and product 
associated with each transaction, the amount spent on each transaction, as well as 
other accounting information relating to the transaction. After formatting the raw 
purchasing data received from the member entities, the system processes the formatted 
data based on predefined supplier and product databases to identify the particular 
supplier and product associated with each transaction. The system then uses the 
processed data, complete with identified purchase transaction information, to manage, 
monitor, and measure the purchasing activity of each entity belonging to the consortium. 
! Accordingly, a manager of the consortium can use this data to negotiate better prices 
1 for products from suppliers by leveraging the buying power of the member entities. 
! While the description of the invention refers to purchasing data for products, 

! systems consistent with the present invention may manage purchasing data for any 
I type transaction. More specifically, the term "product" refers to any type of product, 
I good, service, or commodity. Further, the term "entity" may refer to any type of 
I organization, company, or individual. Finally, while the system is preferably used by a 
I purchasing consortium, the system may also be used for process the purchasing data of 
a single entity. 
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System Implementation 

Fig. 1 illustrates a purchasing data management system 100 consistent with the 
present invention. As shown in Fig. 1, system 100 includes a local system database 
110, a purchasing data processor 120, and a data structure database 130. System 100 
preferably communicates with a central database 150 which stores information used by 
I system 100 to analyze the received purchasing data. System 100 may be implemented 
i using either a personal computer, workstation, network computer, or mainframe 

i 

i 

I computer. 

Processor 120 receives purchasing data from the member entities over a data 

10 1; link 121, via, for example, a keyboard, a disk drive, a CD-ROM, a network link, or a 

I modem. The received purchasing data preferably includes information on a number of 
M purchasing transactions made by the member entity. For each transaction, this 

;| information typically includes information describing: (1) the products purchased by a 

il member entity; (2) the suppliers from whom the products were purchased; (3) the 

15 11 general ledger account associated with each transaction; (4) the cost center associated 

II with each transaction; and (5) the amount spent on each purchase. The general ledger 

j| 

]j account indicates how the member entity classified the transaction according to its 

\ j 

i; 

l! accounting procedures. The cost center refers to the department within the member 

II entity associated with the particular transaction. 

h 

20 I The received purchasing data often contains incomplete or inaccurate 

li information about the supplier and/or product concerning each purchase transaction, 

jl For example, the received data may simply identify a supplier by an acronym or a 
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same may also be true for the portion of the received information concerning the 
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purchased product. To identify the actual supplier and product associated with each 
purchase transaction, system 100 heuristically analyzes the received purchasing data. 

As described in greater detail below, processor 120 formats the received 
purchasing data and stores the formatted data in data structure database 130. System 
100 then processes the formatted purchasing data to identify the supplier and product 
associated with each transaction based on the supplier and product information stored 
in database 110. After identifying the suppliers and products, processor 120 can 
process the data stored in database 130 to produce reports detailing the purchasing 
activity of the entities and of the consortium. 

Database 130 stores the received purchasing data in predefined data fields. In 
particular, database 130 includes an entity-level data structure 132 for each entity in the 
consortium, as well as data structures 134 for the consortium as a whole. The entity- 
level data structure 132 preferably includes a data field for the products purchased by 
the entity, a data field for the suppliers of those products, a data field for the amount 
spent on each transaction, a data field for the general ledger account associated with 
each transaction, and a data field for the cost center associated with each transaction, 
as well as information about the member entity itself. 

The consortium-level data structure 134 contains compiled data on the 
information stored in its associated entity-level data structures 132. Basically, the 
consortium data structure 134 contains aggregate information about the purchasing 
activities of all member entities in the consortium. This information includes the overall 
spending of the consortium, the degree of supplier concentration (indicating the extent 
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I to which member entities purchase products from the same supplier), as well as other 
I! data concerning the purchasing activity of the consortium. 

Local system database 110 stores information used by system 100 to accurately 
ii identify the supplier and product associated with each transaction based on the 

i: 

; I 

5 ji information stored in data structure 132. As shown in Fig. 1 , local system database 110 

1 further Includes a supplier database 112, a product database 114, and a product index 

I 116. While Fig. 1 shows databases 112 and 114, and index 116 as separate units, the 
: information stored therein may also be stored in a single database. 

Supplier database 112 stores information identifying the various suppliers 

10 11 normally used by the member entities. For example, database 112 may store each 

II supplier's name, address, phone number, and fax number. Database 112 also stores a 
i! supplier identification code assigned by system 100 to each supplier. Product database 

\\ 
H 

j; 1 14, on the other hand, includes a listing of the products normally purchased from the 
I suppliers listed in database 112. For example, database 114 may correspond to the 
15 |! United Nations Standard Product and Service Classification (UNSPSC), which is a 
hierarchical classification of various products and services. The product index 116 
contains information used by system 100 to associate products in database 114 with 
information included in the received purchasing data. 

Processor 120 then compares the information in the entity-level data structures 
20 132 with the information stored in local system database 1 1 0 to identify, for each 
transaction, the particular supplier and product associated with that transaction. In 
particular, for each transaction, processor 120 compares the supplier information stored 
in data stmcture 132 with the supplier identification information stored in database 112. 
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Based on this comparison, processor 120 identifies the particular supplier associated 
with each transaction. Similarly, processor 120 identifies the particular product 
associated with each transaction by accessing index 1 16 to determine what products 
correspond to the purchase transactions included in the received purchasing data. 

Index 116 preferably includes a number of indices that define which products in 
database 114 correspond to particular transactions. For example, index 116 may 
include a table indicating what products of database 1 14 are sold by suppliers in 
database 112. In this case, system 100 matches the supplier of the transaction with a 
set of likely product classifications. Index 116 may also include, however, an index 
defining the products in database 114 that correspond to a given United States 
Standard Industry Code (SIC). Thus, when the received purchasing data includes an 
SIC code for a particular transaction, system 100 may access index 1 16 to determine 
the product associated with that SIC code. Index 116 may include a table of key words 
that may be included in the purchasing data and which are associated with a particular 
product in database 114. If one of these key words is included in the purchasing data, 
then system 100 can determine what product corresponds to the received data. Other 
indices may also be used to indicate products based on other purchasing data, such as 
general ledger account or cost center. Finally, the term "index" means any type of 
index, table, catalog, or storage device that contains data used for associating product 
information with any information included in the received purchasing data, and may only 
include data that assists with such product association. 

Index 116 also includes a weight value representing the likelihood that a 
particular product is actually associated with a particular transaction. A weight value is 
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assigned to each product for each type of index. Thus, the weight value indicates the 
lil<elihood that a product is correctly identified by the corresponding index. The weight 
value may also depend upon the member entity providing the purchasing data. In 
systems consistent with the present invention, these weight values are determined 
based on previous product associations determined by system 100 and/or predefined 
criteria entered by a user of system 100. 

For example, Telecommunications Company A may provide local phone service, 
cellular phone service, and cellular telephones. Based on previous product 
associations determined by system 100, index 1 16 may define that when 
Telecommunications Company A is the supplier, the products will have the following 
weights (e.g., on a scale of 1 to 20): 

local phone service (weight = 4); 

cellular phone service (weight = 20); and 

cellular telephones (weight = 7). 
Thus, the high weight value for cellular phone service indicates that a purchasing 
transaction involving Telecommunications Company A likely involves cellular phone 
service. 

In addition to data structure database 130, processor 120 may store the 
processed purchasing data in central database 150. In this embodiment, database 150 
stores the identified information from each transaction. Central database 150 may store 
the processed purchasing data in data structures similar to those of data structures 1 32 
and 134. In either case, the processed purchasing data is preferably stored using multi- 
dimensional data cubes, which are well known in the art. These data cubes store data 
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corresponding to summarized data of data structures 132 and 134. Thus, when system 
100 prepares reports summarizing the purchasing activity of the consortium, system 
100 accesses the data cube corresponding to, for example, spending by product type, 
by supplier, by the consortium, or by a member entity. System 100 or central database 
150 may store information using other data storage techniques, however. 

Central database 150 may also store the information contained in supplier 
database 112, product database 1 14, and product index 116. In particular, central 
database 150 may retain this information for data security purposes and then download 
the required information to local database 1 10 of system 100 on an as-needed basis. In 
this case, central database 150 may store information for a number of consortiums and 
download only that information associated with the consortium for which system 100 is 
managing purchasing data. Central database 150 may then update the supplier and 
product information stored in database 110 based on information learned from the 
management of other consortiums. 

System Operation 

Fig. 2 is an exemplary flowchart of a method for managing the purchasing data 
received from the member entities participating in the purchasing consortium. As 
shown in Fig. 2, system 100 first receives the purchasing data and stores it in data 
structure database 130 (step 205). More specifically, processor 120 formats the 
purchasing data from a member entity and stores it in a corresponding entity-level data 
structure 132. System 100 repeats this operation for purchasing data received from 
each member entity. 
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System 100 then identifies tlie supplier associated with each purchasing 
transaction (step 210). Because of the thousands of ways that the member entities 
often structure their purchasing data, as well as the various acronyms and nicknames 
that they may assign to any given supplier, accurately identifying the supplier 
5 i associated with a transaction is a difficult and arduous task. Accordingly, system 100 
: implements a heuristic supplier identification process that uses the information in the 
I supplier data field of data structure 132 and the supplier and product information of 
li database 110. This supplier identification process is described in greater detail with 
ii respect to Fig. 4. The identified supplier Information is then stored in data structure 132. 
10 ll After identifying the supplier, system 100 then identifies the product associated 

\ with each transaction (step 215). In particular, system 100 compares the data stored in 

data structure 132 with the product information stored in database 1 14 and index 1 16. 
! As described in greater detail below with respect to Fig. 5, system 100 may identify the 
!l product based on information in Index 116. For instance, index 1 16 identifies those 
15 Ij products that likely correspond to a particular supplier, general ledger account, or cost 
I: center described in the received purchasing data. As with the supplier identification 

process, system 100 implements a heuristic identification process to identify the 
li products and stores the identified product information in data structure 132. 

Though steps 205 to 215, system 100 creates data structures 132 and 134 
20 i describing the purchase transactions of the member entities and the consortium. 
1' System 100 can then manipulate or processes the data in these data structures 132 
!; and 134 to prepare reports summarizing the purchasing activity of the member entities 

i I 

and the consortium (step 220). To this end, system 100 summarizes the processed 
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data stored in data structure 132, which, from the above identification procedures, 
includes accurate supplier and product information, as well as other transaction 
information associated with each purchase. 

Figs. 7A and 7B, illustrate exemplary reports of the purchasing activity of a 
consortium and a member entity, respectively. System 100 may output these reports 
using, for example, traditional paper-based reporting methods, interactive reporting 
methods, and/or web-based reporting methods. As shown in Fig. 7A, a consortium- 
level report lists the most commonly used suppliers for a given type of purchase, and 
the amount spent by each entity for each supplier. The consortium-level report may 
contain, for each purchased product, the following information: (1) the total amount 
spent by the consortium; (2) the total amount spent by supplier; (3) the total amount 
spent by each member entity for particular account categories; (4) the degree of 
supplier concentration among the member entities by account category (not shown in 
Fig. 7A); and (5) the top internal departments and ledger accounts associated with each 
transaction in each account category. Other information may be reported, based on the 
needs of the consortium manager. 

Fig. 7B illustrates an exemplary report of the purchasing activities of a particular 
member entity. For example, the report in Fig. 7B shows how much money a particular 
member entity spent on market research, the most popular general ledger accounts for 
purchases made in this area, and the most common suppliers used by the entity in this 
area. System 100 can also generate reports that track spending by a member entity 
before and after it joins the consortium. Further, the consortium may use system 100 to 
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provide a set of normalized suppliers to a member entity to assist the member entity in 
cleaning up their own back office databases. 

The generated reports assist either system 1 00 or a consortium manager to 
negotiate better prices for the member entities. In particular, because system 100 
automatically collects and analyzes the purchasing data received from the member 
; entities, system 100 itself or the consortium manager can efficiently measure the 
I purchasing activity of the consortium on a daily basis. The purchasing activity reported 
l| by system 100 provides information used to better leverage the buying volume of the 
|! consortium entities and thus to obtain better prices. Further, system 100 can identify 
10 i particular suppliers from whom the member entities frequently purchase products. 
I Accordingly, system 100 or the consortium manager can collectively negotiate for the 
l! member entities, rather than the entities doing so independently. 
I| Returning to Fig. 2, system 100 then updates database 110 using the supplier 

I and product identification results obtained from steps 210 and 215 (step 225). System 
15 ;, 100 updates database 1 12 with new information that system 100 obtains about 

j! suppliers during the supplier recognition process of step 210. System 100 also updates 
|i index 1 1 6, based on the identification results, to account for more accurate associations 

i i 
1 . 

I between products and purchase transaction information. The updating of system 100 is 
described in greater detail below with respect to Fig. 6. 
20 i Fig. 3 shows a flowchart illustrating a method for implementing step 210 of Fig. 2. 

I! First, processor 120 creates a consortium-level data structure 134 (step 305). The 

i; created consortium-level data structure 1 34 includes an entry for the name of the 
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consortium, as well as other data fields for storing data summarizing tlie purcliasing 
activity of the consortium. 

Processor 120 then creates entity-level data structures 132 for each member 
entity associated with the consortium-level data structure 134 (step 310). Besides the 
various data fields described above for storing the appropriate information included in 
the purchasing data received from the member entity, entity-level data structures 1 32 
may also include criteria describing the data that system 100 expects to receive from 
the member entities. For example, this information may include a date range applicable 
to the data received from the respective entity. As described below, system 100 may 
use this information to confirm the integrity of the received purchasing data. 

After system 100 creates the data structures, data processor 120 formats the 
received purchasing data and stores the corresponding portions of the received data in 
the respective data fields of structures 132 and 134 (step 315). Although formatting the 
received data prior to processing is optional, system 100 may increase the accuracy of 
the subsequent supplier and product identification steps by formatting the data. 

To format the received data, processor 120 first determines whether the received 
data complies with the format of data structures 132 and 134. To this end, system 100 
ensures that certain data fields are not left blank, and, in such cases, may not store the 
received data. System 100 also truncates or transforms any entered data to comply 
with any storage or format requirements of data structure 132. Additional formatting 
ensures that no duplicate or offsetting transactions are contained in the received data. 
Some further examples of formatting include removing any trailing notations in the 
supplier's name (such as Inc., L.L.P., Co., or Ltd.), compressing nine digit zip codes by 
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removal of dashes, and removing parentheses and dashes from phone and fax 
numbers. 

To ensure the integrity of the received purchasing data, system 100 determines 
that the received data complies with predefined criteria included in data structure 132 
that defines the type of data expected to be received from a member entity. For 
example, system 100 may confirm that the received data is for transactions from a time 
frame expected for the member entity. In addition, system 100 may determine whether 
the received data reflects an appropriate distribution of purchases for the entity over a 
given time frame (e.g., whether spending over the time period falls within preset dollar 
10 I limits). 

Fig. 4 shows a flow chart of a method consistent with the present invention for 
11 implementing the supplier identification step 215 of Fig. 2. As shown in Fig. 4, the 
f method first defines the parameters used by system 100 to identify a supplier (step 
I! 405). Each supplier identification parameter defines a rule for identifying a supplier 
I H 15 1! based on a comparison of the supplier information in data structure 132 with the 
1:5 I! supplier information in database 112. Some exemplary identification parameters 

I include: (1 ) matching supplier name exactly; (2) matching the first 15 characters of 
;; supplier name; (3) matching the first 50% of characters of the supplier name; (4) 
I! comparing acronyms formed from the supplier name; (5) matching the first one or two 
20 words of the supplier name; (6) matching supplier addresses or parts thereof, such as 
i city, zip code, or first 5 digits of zip code; (7) comparing the supplier full phone or fax 
|i number, or parts of the supplier phone or fax number, such as the first 6 digits; or (8) 
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identification parameters, which, for instance, may be developed by evaluating the 
parameter's effectiveness in identifying suppliers. 

System 100 may identify suppliers using one or more of these parameters. For 
example, system 100 may require that parameters (2), (5), and (6) be satisfied before 
determining that the supplier has been accurately identified. System 100 then applies 
the defined identification parameters to the received data (step 410). In particular, a 
supplier is identified when a comparison of the supplier information in data structure 132 
with that in database 112 meets the defined identification parameter(s). If a 
combination of parameters are defined, then system 100 may either require that all 
parameters be satisfied or require that only one parameter be satisfied in order to 
identify a supplier. Identified suppliers in data structure 132 are then assigned the 
supplier identification code associated with the respective supplier information stored in 
supplier database 1 12. Once the supplier is identified, system 100 assigns that 
supplier's identification code stored in database 112 to the supplier information of data 
structure 132. 

System 100 next determines whether to define additional identification 
parameters to further evaluate the suppliers identified by step 410 (step 415). System 
100 makes this determination based on the likelihood that more suppliers may be 
identified by altering the identification parameters or that additional parameters may 
further refine the initial results. For example, system 100 may substitute a more basic 
identification parameter to obtain more results, or may add an additional parameter to 
refine the obtained results. If additional parameters are identified, system 100 defines 
those parameters that the results must meet, and processing returns to step 405. If 
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system 100 determines that additional identification parameters will not yield better 
results (sucli as when even a basic identification parameter does not yield any useful 
results), then system 100 determines whether it should obtain additional supplier 
p information to assist in identifying the supplier (step 420). 
5 In particular, system 100 will obtain additional information when it determines that 

i information not included in entity-level data structure 132 can be obtained from other 
:! sources. System 100 may obtain additional information by matching information of the 
!| unidentified suppliers with information in an external database (not shown) (step 425). 
i For example, system 100 may access a commercial database containing supplier 
10 :1 information, which system 100 can then use to supplement the supplier data received 
! from the member entity and stored in data structure 132 (e.g., it may provide alternative 
li information, such as a different phone number or address). In this case, system 100 
! adds the additional information to the received data stored in data structure 132, and 
! then the processing returns to step 405. 
15 i; When system 100 has identified all possible suppliers, new identities are 

determined for any supplier that could not be determined through steps 405-425 (step 
il 430). System 100 then assigns a supplier identification code to the newly identified 
supplier in data structure 132 and stores the supplier and corresponding identification 
code in database 112. If system 1 00 identifies more than one supplier by the process of 
20 i Fig. 4, then system 100 will display each of those suppliers to a user who can then 
select the appropriate one. Alternatively, system 100 may automatically select the 
appropriate supplier based on predefined criteria describing the likelihood that a 
particular supplier is associated with a particular type of purchase transaction and/or 
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member entity. In either event, once the supplier has been identified, system 100 
modifies data structure 132 to reflect the identified supplier. 

Fig. 5 shows a flow chart of a method consistent with the present invention for 
implementing the product identification step 220 of Fig. 2. To identify a product, system 
100 uses information from the transaction, such as the supplier, ledger account, cost 
center, or purchase description. As shown in Fig. 5, system 100 first determines 
whether the identified supplier of the particular transaction is listed in index 116 (step 
505). If so, then system 100 accesses index 116 to determine the products associated 
with that supplier (step 510). From these products, system 100 selects the product 
having the highest weight value associated with the particular member entity (step 515). 

For suppliers not identified in index 116, system 100 determines the product 
based on other index associations (step 520). For example, system 100 may determine 
if the purchasing data received from the member entity includes an SIC number. If so, 
processor 120 accesses the particular index stored in index 1 16 that correlates SIC 
numbers to products in database 114. 

System 100 may also access a key word index stored in index 116 that 
correlates key words contained in the supplier name to products in database 114. For 
example, if index 116 does not associate any products with the supplier "Joe's Screw 
Widgets," then the words "Joe's," "Screw," and "Widgets" can be compared to entries in 
the key words table. This could then result in the determination that Joe's Screw 
Widgets could sell the products "Screw" or "Widget." System 100 could then select one 
of these products based on the weight values assigned to each of them. In addition to 
the supplier name, system 100 may also perform a key word search using an index 



19 



10 



15 



20 



LAW OFFICES 

INN EC AN, Henderson, 
Farabow, Garrett, 
8 dunner,l.l.p. 

t300 I STREET, N, W. 
A^ASHINGTON, DC 2O0O5 
202-408-4000 



correlating key words found in general ledger data, purchase or product descriptions, 
cost centers, or additional purchasing data with particular products. 

After identifying products in database 1 14 based on index 116, processing 
proceeds to step 515 where system 100 selects the product having the highest weight 
value. Preferably, system 100 identifies products using a number of indexes of index 
116, such that, for each transaction, system 100 compiles all of the identified products 
and combines (e.g., sums) the weights corresponding to the different indexes. System 
100 then selects the product having the highest combined weight value. The combined 
weight value may be determined by summing the different weight values, or by some 
other calculation to arrive at a combined weight value. 

With respect to generating a key word table, one possible method is as follows. 
First, system 1 00 gathers a list of all single words in the product database 114, along 
with its classification association. System 100 then finds all exact matches of these 
words that fall within a lower level of the same classification hierarchy. For a greatly 
simplified example, if system 100 determines that "red" appears in the classification 
VEHICLES:CARS:SPORTSCAR, and "red" appears in the classification 
VEHICLES:CARS:SEDAN, then "red" would be added to the key word table, along with 
an association to the lowest level at which it can be resolved (in this case 
VEHICLES:CARS). Conversely, take the word "mouse". If the word "mouse" appears 
in the classification HOUSEHOLD ITEMS:PEST CONTROL:TRAPS:RODENTS and the 
word "mouse" appears in COMPUTERS:INPUT DEVICES, then there is no lower level 
on which the term can be resolved, and it is not added to the key word table. After 
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formation of the table, system 100 checks to see if any of the added words have been 
explicitly deleted and therefore removes those words. 

Although step 520 of Fig. 5 was described using a number of indexes 116, 
methods and systems consistent with the present invention may use only a single index 
stored in index 116. Further, as opposed to automatically selecting a product, system 
100 may display each identified product to a user, who may then select the appropriate 
product. Once the product has been identified, system 100 modifies data structure 132 
to reflect the identified product. 

To further refine the process for identifying a product, system 100 may use more 
than one product identification criteria. For example, product identification based on 
supplier information alone, may yield a list of possible product results ranked by their 
corresponding weight values. By adding an additional parameter to the identification 
criteria, however, processor 120 can obtain more refined results. Additional product 
identification parameters include general ledger, cost center, and entity information. For 
example, if Supplier A is determined to be associated with Widget A, Widget B, and 
Widget C, the cost center parameter can then be added. With this new parameter, 
system 100 may determine that Widget C is the only product associated with Supplier A 
at Cost Center 1 , thus improving the accuracy of the identified product. 

Updating of system 100, as in step 230 of Fig. 2, can encompass a variety of 
different activities. For instance, system 100 updates supplier information 112 with the 
new supplier information included in the purchasing data received from the member 
entities. System 100 also updates the table of key words in index 116 based on 
changes to the product database 1 14. System 100 may also determine that particular 
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il identification parameters more accurately identify suppliers or products, in which case, 
I the parameters can be ranked based on their level of accuracy. Similarly, product 

I indexes 1 1 6 and their respective weight values can be updated based on the new 
results of system 100. 

5 I Updating the efficiency of supplier identification parameters permits system 100 

to recommend sets of identification parameters for use during step 405 of Fig. 4. Using 
il all of the purchasing data stored in the central database 150, for instance, system 100 

II can apply a predetermined set of parameter combinations to identify suppliers. System 
! 100 then compares these suppliers to those identified during the operation of system 

Ci 10 II 100 with respect to a particular member entity. True positives, true negatives, false 
■J II positives, and false negatives are assessed, and the efficiency of each set of parameter 

^.t 1: combinations is determined. Based on the determined efficiency, the most efficient 

i parameters are recommended by system 100. 

W 

I = Fig. 6 is a flow chart illustrating a method for updating the product indices and 

m 15 : respective weight values of index 116. After resetting all previously determined weights, 

O II system 1 00 determines a new weight value for each prciduct type in each index of index 

! 116 (step 605). In other words, each product in each index is assigned a standard 

1 weight value. Each index, however, may have a different standard weight value 

I depending upon how well that index determines products based on the information in 

20 il the received purchasing data. For example, system 100 may assign a high standard 

' weight value to products in the supplier-to-product index (which gives a more reliable 

I; determination of the product), a medium standard weight value in the SIC-to-product 

i ' 
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index, and a low standard weight value in tine key word-to-product index (whicli gives a 
less reliable determination of the product). 

System 100 then looks at the final product associations made using each index, 
and determines a new weight value for each product based on the relative accuracy of 
the particular association (step 610). In particular, for each product in each index, 
system 100 sums the number of times that the product was eventually identified using 
that index. System 100 then combines (e.g., multiplies) that number by the standard 
weight value for that index. The newly updated weight values are then ranked and then 
stored in index 116 (step 615). 

Conclusion 

As discussed above, systems and methods consistent with the present invention 
manage purchasing data received from entities in a purchasing consortium. The 
system and method automatically identifies suppliers and products referred to in the 
received purchasing data. The system then reports the resulting categorized data for 
use in creating and operating the consortium or for use by the member entity. 

The above-noted features and other aspects and principles of the present 
invention may be implemented in various system or network environments to provide 
automated computational tools for receiving purchasing data, identifying suppliers, and 
organizing data, reporting organized data, storing associations extracted from the 
organized data, and administering stored data. Such environments and applications 
j may be specifically constructed for performing various processes and operations of the 
I invention or they may include a general purpose computer or computing platform 

i 

i selectively activated or reconfigured by program code to provide the necessary 
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|1 functionality. The processes disclosed herein are not inherently related to any particular 
i computer or apparatus, and may be implemented by a suitable combination of 
I hardware, software, and/or firmware. For example, various general purpose machines 
may be used with programs written in accordance with the teachings of the invention, or 
5 i it may be more convenient to construct a specialized apparatus or system to perform 

I the required methods and techniques. The present invention also relates to computer 

i readable media that include program instruction or program code for performing various 
li computer-implemented operations based on the methods and processes of the 

i| invention. The media and program instructions may be those specifically designed and 

i 

1 0 P constructed for the purposes of the invention, or they may be of the kind of well-known 

II and available to those having skill in the computer software arts. Examples of program 
li instructions include both machine code, such as produced by a compiler, and files 

: containing a high level code that can be executed by the computer using an interpreter. 
Other modifications and embodiments of the invention will be apparent to those 
15 i skilled in the art from consideration of the specification and practice of the invention 

ii disclosed herein. It is intended that the specification and examples be considered as 
i exemplary only, with a true scope and spirit of the invention being indicated by the 

I following claims. 
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